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REMARKS 

The Office Action mailed March 13, 2009, considered and rejected claims 1, 3-8, 10, 12- 
15 and 17-25. Claim 1, 3-8, 10, 12-15 and 17-25 were rejected under 35 U.S.C. § 112 as failing 
to comply with the written description requirement. Claims 1, 3, 4, 6, 7, 10, 12, 13, 14, 15, 17, 
18-22, and 24 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Dworkin (U.S. 
Patent No. 4,992,940), in view of Rossides (U.S. Patent No. 5,359,508). Claim 5, 8 and 23 were 
rejected under 35 U.S.C. § 103(a) as being unpatentable over Dworkin in view of Rossides in 
view of Singh (U.S. Publ. No. 2001/004731 1). Claim 25 was rejected under 35 U.S.C. § 103(a) 
as being unpatentable over Dworkin in view of Rossides as apphed to Claim 1 above, further in 
view of Businessline: "In view web of e-services". May 8, 2002.* 
Overview of the Invention 

The present invention is directed to embodiments for updating business partner attributes 
in a business process without having to recompile the business process application each time an 
update occurs. As has been addressed in previous responses, a business process, as used in the 
specification, is a term of art that refers to a process of a web service such as a process defined in 
the business process execution language.^ Conventional business process applications require a 
user to program the partner information directly into the business process application. See Spec, 
pg. 1, t 2. Therefore, when any update was made to the partner information, the business 
process application would have to be recompiled before the updates would be included.^ Thus, a 
key benefit of the invention is that the business process application is only deployed once, while 
partner attributes can be added and enlisted in an independent fashion. 



^ Although the prior art status of the cited art is not being challenged at this time, Apphcant reserves the right to 
challenge the prior art status of the cited art at any appropriate time, should it arise. Accordingly, any arguments and 
amendments made herein should not be construed as acquiescing to any prior art status of the cited art. 

^ For an explanation of BPEL and business processes, see A Hands-on Introduction to BPEL , available at 
http://www.oracle.com/technology/pub/articles/matjaz_bpell .html. Further support for this definition of a business 
process may be found in Business Processes m a Web Services World , available at 

http://wwrw.ibm.com/developerworks/webservices/library/ws-bpelvvfp/ (stating that "A business process specifies the 
potential execution order of operations fi-om a collection of Web services, the data shared between these Web 
services, which partners are involved and how they are involved in the business process, joint exception handling 
for collections of Web services, and other issues involving how multiple service and organizations participate.") 
second enphasis added); 

For an exanq)le of how partner information is included directly m the business process, see the above referenced 
webpage in the section entitled "Step 3 : Define Partner Link Types." 



Page 8 of 13 



Application No. 10/617,904 

Amendment "D" dated May 13, 2009 

Reply to FINAL OfBce Action mailed March 13, 2009 

Support for this interpretation of business process is provided by examining the use of the 
term throughout the specification. See MPEP 2111.01 ("The specification should also be relied 
on for more than just explicit lexicography or clear disavowal of claim scope to determine the 
meaning of a claim term when apphcant acts as his or her own lexicographer; the meaning of a 
particular claim term may be defined by impKcation, that is, according to the usage of the term 
in the context in the specification. See Phillips v. AWH Corp., 415 F.3d 1303, 75 USPQ2d 1321 
(Fed. Cir. 2005)") (emphasis added). For example, the specification states that "[i]n one 
embodiment, business process execution engine is implemented with an XLANG Scheduler 
Engine." See Tf 18; see also Claim 25. XLANG is a web service orchestration language that was 
created by Microsoft and has been superseded by BPEL."* Further, the specification states that 
the "[bjusiness process may be created viith a visual design tool, such as Orchesti-ation 
Designer." See \ 19. Orchestration Designer enables a user to design and implement executable 
business processes.^ Therefore, when read in context, the term business process as used in the 
specification has a specific meaning that would be understood to one or ordinary skill in the art. 
When reading the terms such as "executable business process," 'business process execution 
engine," "business partners," "XLANG Scheduler Engine," and "Orchestration Designer," one of 
ordinary skill in the art would certainly understand the invention that is being described. These 
terms are common terms that appear in any reference that describes a business process written in 
BPEL (or its predecessor XLANG). 

The examiner is therefore required to give the term business process the meaning that 
was intended as evidenced by its use in the specification, and by which it would be commonly 
understood by those of ordinary skill in the art of designing computer implemented business 
processes. However, in the current response, the examiner has completely ignored the term 
"business process" in the claims. As previously addressed, neither Dworkin nor Rossides have 
anything to do with a business process. The examiner is reminded that "The Patent and 
Trademark Office ("PTO") determines the scope of claims in patent applications not solely on 
the basis of the claim language, but upon giving claims their broadest reasonable construction 

See, e.g. http://xml.coverpages.org/xlang.html. It is also noted that when searching for XLANG on Wikipedia, the 
search is redirected to the page on BPEL. 

^ See, e.g. http://technet.microsoft.cotn/en-us/library/aa560470.aspx ("BizTalk Orchestration Designer is a tool for 
conveniently creating visual representations of your business processes that are automatically reflected in underlying 
code and which you build into an executable module. It provides a wide variety of shapes that correspond to 
different actions that you might want to perform."). 
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'in light of the specification as it would be interpreted by one of ordinary skill in the art.'" 
Phillips V. AWHCorp., 415 F.3d 1303 (Fed. Cir. 2005). As stated above, one of ordinary skill in 
the art (i.e. one having familiarity with designing business processes using such tools as the 
XLANG Scheduler Engine and the Orchestration Designer) would certainly interpret the term 
business process differently than the examiner is currently doing. The examiner's interpretation 
is not reasonable "in light of the specification." Therefore, Applicant requests that the examiner 
interpret the claims using their intended meaning as defined by the specification. 
Section 112 Rejections 

The independent claims were rejected for being indefinite and not supported by the 
specification. Specifically, the examiner has asserted that the limitations "but that does not 
include business partner attributes," "subsequent to selecting the first business partner," and 
"subsequent to modifying the attribute and without recompiling the compiled business process 
application" are not supported by the specification. Applicant submits, however, that these 
limitations define the key aspects of the invention which are explained in the specification. 
Paragraph 2, for example, with respect to prior art business processes states that: "Conventional 
computer implemented business process apphcations require a user to program the partner 
information directly into the business process application. In this example, the identification of 
the business partner and certain attributes, such as address and contact information, are included 
or hard coded directly into the business process application." Paragraph 3 continues: "Among 
other disadvantages, coding partner information directly into a business process application 
results in a requirement that the business process application be modified and recompiled when 
business partners or business partner attributes change." Paragraph 5 states that: "Aspects of 
the present invention address one or more of the issues mentioned above, thereby providing a 
computer implemented business process system that allows users to dynamically manage 
business partners without modifying the business process.... Business partners can be added, 
modified and deleted without changing tiie business process." Finally, paragraph 19 states that 
"[d]efining partners in terms of selection criteria allows for the management of partnership 
attiibutes without modifying and/or recompiling the business process." The limitation "but that 
does not include business partner attributes" is another way of stating that the compiled business 
process application only contains selection criteria rather than having the business partner 
attributes (e.g. address and contact information, see If 2) hard coded into the business process 
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application. Further, the specification states that the business partner attributes are contained in a 
separate list rather than the business process apphcation. See \ 18. Therefore, there is ample 
support for this limitation because it is the primary purpose of the invention (i.e. to leave the 
business partner attributes out of the business process so that it need not be recompiled each time 
an attribute changes). 

The remaining two limitations which were rejected are also adequately supported in the 
specification. The claims are directed to a specific instance were the user dynamically modifies 
the business partner attributes without modifying or recompiling the business process. The 
specification explicitly states that the invention allows users "to dynamically manage business 
partners without modifying the business process," and "allows for the management of partner 
attributes without modifying and/or recompiling the business process." f 5, 19. The language 
used in the claims simply states a specific instance of this dynamic management, namely that a 
user can change an attribute of the first business partner without having to recompile the business 
process and still have the business process select the partner using the selection criteria. This 
language was originally added to assist the examiner in understanding the invention, but is not 
necessary to overcome the cited art because the art does not even teach that an attribute of a 
business partner can be changed without recompiling the business process. 

Further, these limitations are not indefinite. The first limitation is intended to mean that 
the business partner attributes are contained in a separate hst rather than in the business process 
apphcation as is stated throughout the specification. The selection criteria are not business 
process attributes and are not specific to any business partner. The selection criteria may be 
anything for selecting the appropriate business partner such as for instructing the "business 
process execution engine to select the partner having the lowest cost for the widget." T| 19. The 
second and third limitations are also not indefinite. Any attribute of a business partner may be 
changed. For example, the address or contact information may be changed for a first business 
partner. This change may be made to the attributes contained in the separate list without 
recompiling the business process. However, the first business partner, for example, may still 
offer the lowest cost widget in which case the first business partner would still be selected. The 
key is that the change in the attributes may be made without recompiling the business process 
because the business process does not contain the attributes. For these reasons. Applicant 
submits that the claims meet the requirements under section 112. 
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Prior Art Rejections 

In rejecting the claims, the examiner is relying on dictionary definitions of the terms 
"engine" and "compiler." However, the claims do not simply recite an engine or a compiler. To 
the contrary, the claims recite a "business process execution engine" and a "compiled business 
process application." A business process execution engine is a specific type of engine that is 
used to execute business processes such as the XLANG Scheduler Engine of claim 25. It is not 
the same as a search engine. Specifically, a search engine does not have the capability to execute 
business processes. Further, the Federal Circuit has made it clear that the specification, rather 
than a dictionary, should be given primary weight in determining the intended meaning of a 
claimed limitation. See Phillips. 

As addressed previously, the cited art does not address business processes, a business 
process execution engine, or the storing of the partner attributes in a separate list so that the 
attributes may be changed without recompiling the business process. Therefore, these references 
cannot teach or suggest the Hmitations of the claims. 

In view of the foregoing, Apphcant respectfully submits that the other rejections to the 
claims are now moot and do not, therefore, need to be addressed individually at this time. It will 
be appreciated, however, that this should not be construed as Applicant acquiescing to any of the 
purported teachings or assertions made in the last action regarding the cited art or the pending 
application, including any official notice. Instead, Apphcant reserves the right to challenge any 
of the purported teachings or assertions made in the last action at any appropriate time in the 
future, should the need arise. Furthermore, to the extent that the Examiner has rehed on any 
Official Notice, explicitly or implicitly, Applicant specifically requests that the Examiner 
provide references supporting the teachings officially noticed, as well as the required motivation 
or suggestion to combine the relied upon notice with the other art of record. 

In the event that the Examiner finds remaining impediment to a prompt allowance of this 
application that may be clarified through a telephone interview, the Examiner is requested to 
contact the undersigned attorney at (801) 533-9800. 
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Dated this 13 day of May, 2009. 



Respectfully submitted, 



RICK D. NYDEGGER 
Registration No. 28,651 
BRIAN D.TUCKER 
Registration No. 61,550 
Attorneys for Applicant 
Customer No. 047973 
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